백엔드 보안: 인증·인가와 코드의 책임

인증과 인가를 구분하고, 코드 구조와 API 문서에 보안 책임을 남깁니다.

QCN

백엔드 보안의 첫걸음: 인증과 인가

  • 로그인 성공과 작업 권한을 나눠 확인합니다.
  • 게시판 삭제 기능을 예로 서버 검증 위치와 테스트 기준을 정합니다.
QCN

1. 인증 (Authentication) 이란?

  • '누구인지' 신원을 확인하는 과정입니다.
  • 가장 대표적인 예는 로그인 입니다.

마치 건물에 들어갈 때 출입증이나 신분증을 보여주는 것과 같아요.
"제가 바로 OOO 입니다." 라고 증명하는 단계죠.

  • 예시
    • 아이디/비밀번호 입력
    • 지문, 얼굴 인식
    • 일회용 비밀번호(OTP)
QCN

2. 인가 (Authorization) 란? (1/2)

  • '무엇을 할 수 있는지' 권한을 확인하고 부여하는 과정입니다.

  • 인증을 통과한 사용자가 특정 자원이나 기능에 접근할 수 있는지 결정합니다.

출입증을 보여주고 건물에 들어왔더라도, 모든 사무실에 들어갈 수는 없죠.
본인에게 허가된 곳만 들어갈 수 있는 것, 이것이 바로 인가입니다.

QCN

2. 인가 (Authorization) 란? (2/2)

  • 예시
    • 관리자는 게시물을 삭제할 수 있지만, 일반 사용자는 불가능합니다.
    • 유료 회원은 특별 영상을 볼 수 있지만, 무료 회원은 불가능합니다.
QCN

인증과 인가는 왜 필요할까요? (1/2)

  • 사용자 정보 보호

    • 허가되지 않은 사람이 나의 개인정보나 글을 볼 수 없도록 보호합니다.

  • 데이터 무결성 유지

    • 권한 없는 사용자가 중요한 데이터를 함부로 수정하거나 삭제하는 것을 막습니다.

  • 악의적인 접근 방지

    • 해커나 악성 봇으로부터 우리의 소중한 시스템을 안전하게 지킵니다.
QCN

인증과 인가는 왜 필요할까요? (2/2)

"인증은 신분증 검사, 인가는 입장권 검사라고 생각하면 쉬워요. 백엔드에서 이 두 가지를 잘 관리해야 우리 앱이 안전하게 운영될 수 있죠!"

QCN

잠깐, 구분해 보기

로그인한 사용자가 다른 사람의 글을 삭제할 수 있다면 무엇이 빠졌을까요?

QCN

HandStack에서의 인증/인가 (미리보기)

  • 실제 공개 여부는 거래의 Authorize, 호스트·모듈 설정, 업무 로직을 대조해 확인합니다.
  • 토큰 기반 인증(JWT)은 신원 검증에, 역할 기반 인가는 허용 작업 판단에 사용합니다.
  • 역할만으로 충분하지 않은 작업에는 글 소유자·조직·데이터 범위도 검사합니다.
QCN

핸즈온: 보안 감각 키우기 (코드 실습 없음)

  • 잠시 시간을 내어 '개인정보 유출', '해킹 사례' 등 보안 관련 뉴스 기사나 영상을 검색해 보세요.

  • 사례의 실패 원인을 인증·인가·민감정보 노출로 나눕니다.

  • 비로그인·일반 사용자·관리자별 조회·수정·삭제 허용표를 작성합니다.

  • 개발자에게 보안은 선택이 아닌 필수입니다.

QCN

보안 규칙을 코드에 남기기

  • 이제까지 배운 백엔드 개발 흐름을 정리하고, 더 좋은 개발자가 되기 위한 길을 함께 살펴봅니다.
QCN

좋은 백엔드 코드란 무엇일까?

  • 변경할 규칙과 테스트할 경계를 코드에서 빠르게 찾을 수 있어야 합니다.
QCN

다시보는 계층형 아키텍처

  • 다음은 일반적인 책임 분리 방식입니다. HandStack에서는 Controller·거래 계약·실행 모듈에 각 책임을 대응시켜 읽습니다.

    • Controller (요청 처리 및 응답)
    • Service/Business Logic (핵심 비즈니스 규칙 처리)
    • Repository/Model (데이터베이스와의 소통)

  • 왜 역할을 나눌까요?

    • 코드를 이해하기 쉽고, 각자 맡은 역할에 집중할 수 있습니다.
    • 기능 변경 시 수정할 부분을 찾기 쉽고, 유지보수와 테스트가 용이해집니다.
QCN

클린 코드 맛보기 (1/2)

  • 클린 코드란, 동료 개발자가 읽고 이해하기 쉬운 코드입니다.

  • 코드는 한번 작성하고 끝나는 것이 아니라, 계속 읽히고 수정됩니다.

  • 간단한 원칙

    • 의미 있는 이름 짓기: 변수/함수 이름만 봐도 역할을 알 수 있게
      (예: a (X) -> articleCount (O))
QCN

클린 코드 맛보기 (2/2)

- **하나의 함수는 하나의 일만**: 여러 기능을 하는 함수는 작게 분리
  (예: `GetArticleAndSendEmail()` (X) -> `GetArticle()`, `SendEmail()` (O))
QCN

API 문서화의 중요성

  • 우리가 만든 API를 다른 사람(프론트엔드 개발자, 동료)은 어떻게 사용해야 할까요?

  • API 명세서(문서)는 협업과 소통을 위한 필수 도구입니다.

  • Swagger/OpenAPI 같은 도구를 사용하면 API를 자동으로 문서화할 수 있습니다.

  • Controller의 OpenAPI 문서와 거래별 계약·입출력·권한 문서를 함께 관리합니다.

QCN

핸즈온: 내 코드 돌아보기

  • 지금까지 본인이 작성한 컨트롤러나 모델 파일을 다시 열어보세요.
  • 그리고 스스로에게 질문을 던져보세요.

"이 변수 이름은 더 좋은 이름이 없을까?"

"이 코드는 너무 긴데, 함수로 따로 빼면 더 깔끔하지 않을까?"

"한 달 뒤에 내가 이 코드를 다시 봐도 바로 이해할 수 있을까?"

  • 이렇게 고민하는 것부터가 좋은 개발자의 시작입니다.
QCN

HandStack이 좋은 습관을 만드는 이유

계약·모듈·화면 파일을 분리하면 변경 위치를 찾기 쉽습니다. 구조만으로 보안이나 품질이 보장되지는 않습니다.

  • 입력 검증·업무 규칙·권한 검사 위치를 기록합니다.
  • 배포본이나 템플릿의 기본값을 업무에 맞게 검토합니다.
QCN

보안을 확인할 기준

  • 비로그인·일반 사용자·관리자의 허용 작업을 표로 정합니다.
  • 서버에서 인증과 자원별 인가를 각각 시험합니다.
  • 책임을 나눈 코드와 API 문서에 실패 응답·검증 기준을 남깁니다.
QCN

발표: 첫 화면의 목표를 말한 뒤 핵심 개념과 예제로 진행합니다. 확인 질문 뒤에는 답할 시간을 주고, 마지막 완료 기준을 남겨 질문을 받습니다. 발표 구성 참고: MIT OpenCourseWare, Patrick Winston, How to Speak (2018), https://ocw.mit.edu/courses/res-tll-005-how-to-speak-january-iap-2018/pages/how-to-speak/

질문 후 잠시 기다립니다. 답이 없으면 앞에서 본 예제를 다시 가리킵니다. 확인할 답: 인증만 통과한 상태입니다. 서버에서 역할과 대상 자원의 소유권 등 인가 규칙을 검사해야 합니다. 다음 주제로 넘어가기 전에 차이를 청중의 표현으로 한 번 확인합니다.

질문을 받는 동안 이 확인 기준을 화면에 남깁니다. 청중이 자신의 업무에 적용할 다음 행동 하나를 고르게 합니다.